Unicast or multicast traffic in a packet-switched network can be protected against failures using notification packets. In case of a change in the packet-switched network, a reconfiguration (rerouting) is needed, which should be as fast as possible.
Several Fast Reroute (FRR) protocols are known for reconfiguring a network responsive to a change in the network topology. Exemplary FRR procedures are described in I J. Wijnands, A. Császár, “Tree Notification to Improve Multicast Fast Reroute”, internet draft, available online: http://tools.ietf.org/html/draft-wijnands-rtgwg-mcastfrr-tn-00, Oct. 15, 2012 (“Wijnands”); and A. Császár, G. Enyedi, J. Tantsura, S. Kini, 3. Sucec, S. Das, “IP Fast Re-Route with Fast Notification”, Internet draft, available online: http://tools.ietf.org/html/draft-csaszar-rtgwg-ipfrr-fn-01, Feb. 25, 2013 (“Császár”). These references are incorporated herein in their entirety by reference.
The FRR procedures described in Wijnands and Császár propagate a failure notification packet through the network, which can be processed and forwarded by linecards at each network node without control plane involvement. Because the control plane is not involved, failure reaction can be significantly faster than traditional approaches. FRR using notification packets is especially useful for protecting multicast traffic.
A common problem of notification packets is that a malicious attacker may record the notification packet and inject replayed notification packets into the communications network, thus causing an unnecessary or even harmful reconfiguration of the network. It has been found that replay attacks can occur even when notification packets are digitally signed or encrypted to prevent injection of malicious notifications.
For unicast traffic, one solution for protecting notification packets against replay and other attacks is to use an Interior Gateway Protocol (IGP), such as the Open Shortest Path First (OPSF) protocol or Intermediate System to Intermediate System (ISIS) protocol, to create a hash value from a link state database. Since the link state database should be global in a stable state and should change after each failure, this hash value can be used in a global sequence number. This solution is not available if there is no link state database, which is typically the case with multi-cast routing protocols.
The IPsec protocol uses a sequence number for all possible sources. This solution scales well because a limited number of nodes is communicating with each other at a time. Although it is problematic with IPsec, it is possible to keep up one sequence number per node, but this approach would result in communication with all of the network nodes. Typically with IPsec, each network node is communicating with only a small portion of the nodes in the network. As an example, Protocol Independent Multicast (PIM) uses IPsec for communicating only with an immediate neighbor. If there is a need to communicate with another node, the node needs to set up a new connection and agree on a sequence number. For FRR procedures, there usually is insufficient time for such synchronization.
Another possible solution to combat replay and other attacks is for each node to maintain a sequence number for all other nodes in the network, which would require that each node communicates with the other nodes in the network. This solution, however, makes scaling more difficult. With protocols such as PIM and the Routing Information Protocol (RIP), scaling would be easier because each node is communicating only with its neighboring nodes.